InfoMagic Standards 1994 January

home *** CD-ROM | disk | FTP | other *** search

/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / misc / merit / noop / plans / mitre_rt.v2 < prev next >

Wrap

Internet Message Format | 1991-04-07 | 24KB

From noop-owner@merit.edu Wed Mar 20 12:40:16 1991 Received: Wed, 20 Mar 91 12:40:13 EST from merit.edu by rivendell.merit.edu (5.51/1.6) Received: by merit.edu (5.65/1123-1.0) id AA07773; Wed, 20 Mar 91 12:37:43 -0500 Received: from gateway.mitre.org by merit.edu (5.65/1123-1.0) id AA07769; Wed, 20 Mar 91 12:37:36 -0500 Received: from dockside.mitre.org by gateway.mitre.org (5.61/SMI-2.2) id AA29195; Wed, 20 Mar 91 12:37:18 -0500 Return-Path: <lazear@gateway.mitre.org> Received: by dockside.mitre.org (5.54/SMI-2.2) id AA03639; Wed, 20 Mar 91 12:38:53 EST Date: Wed, 20 Mar 91 12:38:53 EST From: lazear@gateway.mitre.org Message-Id: <9103201738.AA03639@dockside.mitre.org> To: mitre-osi@gateway.mitre.org Subject: New OSI Routing plan Cc: barns@gateway.mitre.org, noop@merit.edu, sallyt@gateway.mitre.org, skh@merit.edu Status: RO Here is the updated OSI routing plan for MITRE's pilot effort. This is a major rewrite from the previous one and includes a lot of recently-discussed notions about whether being a "good Internet citizen" is good for MITRE. Again, this is preliminary and needs your comments. Walt =============================================================== SECTION 1 OSI ROUTING NOTE: This draft is dated 20 March 1991. This paper is a preliminary draft of the proposed routing architecture, implementation approach, and outstanding issues. The text here is composed of distilled correspondence with national-level standards participants, members of implementors groups, and MITRE staff. It is rough and intended as a working draft to stimulate early thought about the design and implementation of OSI routing. The reader is encouraged to discuss the contents, suggest improvements, and correct misconceptions with the author (Walt Lazear -- lazear@gateway.mitre.org). This task is to define and implement OSI routing in MITRE. It will be performed jointly by W31 (John McGuthry and Mike Saintcross) and W154 (Clay Speicher and John Jamison). The cisco configurations, software bugs, and lessons-learned will be documented. 1.1 ADDRESSES 1.1.1 General Situation The GOSIP format for the NSAP is the format of choice for Government and Internet systems and should match the format being defined by ANSI this year. Routing between the GOSIP (NIST) and ANSI formats should not be an issue. There are a number of hierarchy levels in the GOSIP NSAP. Some of them are of interest (with octet count in parens): AA (3) - Administrative Authority - normally given to a regional. RD (2) - Routing Domain - normally given to a campus or company. Area (2) - Area within RD - used within a campus or company System-ID (6)- SID of a host or router Selector(1) - Protocol number (like TCP port) In looking at the address hierarchy structure in NSAPs, it becomes clear that the so-called backbones cannot occupy a level by themselves. They belong at the AA level, but they should not consume this large address space exclusively. It also seems appropriate to have the regionals obtain an AA and make their subscribers (companies and campuses) into Routing Domains. We should encourage our regionals (Alternet and Nearnet) to apply directly to GSA for an AA. This can be done now at no cost. The address and procedure has been posted on the Internet to the noop@merit.edu list. The person in charge is Tom DeWitt. His email address is tbd@isdn.ncsl.nist.gov. The formal assignment action requires that you send a genuine hardcopy letter signed by someone with a very important sounding title. The purpose of this is to try to prevent two or more parts of the same organization from making independent requests. The mailing address is: Telecommunications Customer Requirements Office U.S. General Services Administration Information Resource Management Service Office of Telecommunications Services 18th and F Streets, N.W. Washington, DC 20405 The requestor provides the following information: NSAP ADMINISTRATIVE AUTHORITY IDENTIFIER (AAI) REQUEST FORM Requestor's name: Title: Organization: Postal Address: Phone Number: Fax Number: E-Mail Address: Date Needed: Statement of Requirement: This is where you say why you need it. Figure 1. Making a company or campus an RD gives the Area level to the subscribers to use within their organization for subnetting (by buildings, labs, etc., without resorting to funny System- ID numbers (to create subnets) and without breaking the use of MAC addresses (Ethernet) as System-ID (48 bits, 6 octets). This works well for companies and campuses connected to a single regional net. Organizations with multiple connections to regionals, however, present a different set of requirements and demand a different solution (at least until better tools are available to support such complex situations). 1.1.2 MITRE Situation MITRE has a complex topology that does not fit well within the strictly hierarchical NSAP address space. Notably, MITRE has connections to three regional networks (Milnet, Alternet, and Nearnet). OSINET could be considered as a fourth regional network. MITRE has nationwide geographic dispersion (Massachusetts, Virginia, Colorado, and New Jersey are linked as one corporate network). As discussed in the Callon, Colella, and Gardner paper "Guidelines for OSI NSAP Allocation in the Internet," the use of a regional's prefix in a company's NSAP means that the company's addresses will have to be changed if the connection point is changed. This would mean that some portion of MITRE's addresses would change each time one of the four connection points was changed or dropped. We recognize that the address change is an architectural "feature" of the GOSIP structure and that tools will be needed to support such turbulence, but that support is not in place: The routing protocols do not carry enough alternate addresses for a node to make this turbulence practical. There is no widespread end-system software that chooses another NSAP address if errors are received. There is no regional support to redirect packets to new routes for sites that changed addresses. There is no support in the Transport protocols to change NSAPs if one becomes unreachable. There is no Directory Services X.500 help for the transition. Work on defining the necessary support is already underway in such standards bodies as ANSI X3S3.3 and the IETF, but the efforts are slow and not well supported at present. This can be expected to change as more installations of OSI protocols require the suppport. 1.1.3 Corporate Administrative Authority To avoid the internal administrative burden discussed above, MITRE should obtain a single AA directly from GSA. Addresses should be assigned and registered by each campus computer center, as is done with IP and Ethernet addresses now. Registration logs should be exchanged among interconnected campuses, to aid in monitoring network traffic and solving network problems. Arrangements will be made with the connected regionals to advertise a route to the MITRE AA. 1.1.4 Campus Routing Domains Each campus should obtain an RD domain identifier from the MITRE AA address space. For example, Washington, Bedford, and Colorado Springs should each have an RD assigned to them. As initial participants in the Pilot effort, these sites can get separate RDs from Alternet, to allow them to establish registration and assignment procedures in the style of the production system. Some experimental systems in Bedford and Washington will have to change from OSINET or private NSAP formats to the GOSIP one. The hierarchical levels within the NSAP means that, in the case of fully connected sites, traffic will be routed to a Well-known Entry Point (WEP) for the site RD. From there, internal links can be used to route within the site Routing Domain (RD). The external OSI infrastructure won't route to a separate MITRE island. Non-connected sites are discussed below. 1.1.5 Building Areas Initially, we should try to assign addresses as we expect to see them in the long run. We propose that routing Areas be assigned within an RD by building. Extra-large buildings can be subdivided into as many Areas as make sense. As familiarity with OSI routing protocols grows, campus administrators may decide to subdivide further. 1.1.6 System IDs System IDs should be MAC-based (Ethernet), or assigned from the locally-assigned pool of Ethernet addresses (setting the x'40' bit in the first octet), using the central registry at the computer centers. The local pool can be used to embed meaningful numbers in the System ID, such as IP address or serial number. The System ID may also be a simple number assigned from a sequential pool or registry. The benefits in using a MAC address as the System ID are to guarantee uniqueness of the NSAP address thus generated, to allow the process to be automated, and to ease the monitoring of a LAN by address. The benefit of using an IP address is again uniqueness (although we don't want to have to assign IP addresses to OSI-only hosts forever). The danger in embedding real information in the System ID is that some program or local protocl will try to interpret this information (that is, "reverse engineer" a MAC or IP address). Such efforts are naive and in error. 1.1.7 Site Routing Domains Each site, regardless of size, should be assigned a Routing Domain number now. They can develop their OSI environment as an "island", using the guidelines developed for the main campuses to create Areas and System-IDs. When and if they connect to the corporate LAN, they will fit correctly into MITRE's addressing and routing scheme. Further, if they are going to use something (like DDN) for Internet connectivity, then they should "additionally" get a block of RD identifiers from their connectivity provider (eg, regional net). This way they will fit easily into the global routing scheme. Access through this additional address space is independent of whether the site has connected directly to the corporate LAN. There is the administrative burden (discussed above) of changing these additional addresses if the regional provider is changed or dropped. 1.2 PROTOCOLS All routers on the MITRE backbone are ciscos and as a temporary measure we can use their proprietary IGRP solution to the IS-IS lack. When the standard solution appears, we can shift to it. 1.2.1 Static Static routing will be the primary mode in the IE Testbed to keep the routing simple and common across all types of components (eg, ciscos and MicroVaxes). 1.2.2 Dynamic The goal is to use cisco's dynamic OSI IGRP protocol on the production LAN. Cisco says if you are running a version of the ROMs after 8.1(19), you should be able to use dynamic routing (with ISO IGRP). 1.2.3 Management The Internet has defined a MIB (in RFC 1162) for monitoring CLNP and ES-IS with SNMP. This is a potential way to monitor the ciscos, but will need exploration. We will be incorporating this MIB into the SunNet Manager software to test the monitoring of the cisco OSI routing. 1.3 SECURITY Initially, we will not try to bridge the MITRE security perimeter with OSI protocols. Applications may use some form of "tunnelling" at the application layer, or we might use a couple of transport layer gateways (TCP to TP4) to accomplish this. In the end, we'll certainly want to put the full stack through the perimeter. This will be a topic of discussion for future Information Security Committee meetings. We'd like to duplicate the filtering available under TCP/IP. The "discard" option on the CLNS ROUTE command seems to be the only mechanism to limit traffic. The full "permit/deny" access-list mechanism for CLNS is desirable, but is still under development. Early email exchanges with cisco about this facility were encouraging. 1.4 TESTING 1.4.1 I.E. Testbed (outside) We have been talking about how to hook in the IE Testbed to Alternet for OSI purposes. One of the guiding thoughts that came out of the discussion is that we don't want to upset the testbed functioning. This means keeping the logging of IP traffic consistent with the past two years collection. It means keeping OSI traffic segregated when possible. It means not bouncing operational testbed gateways frequently. There are really two efforts going on. One is to talk to the outside world thru Alternet. The other is to route within the testbed. These turn out to be parallel efforts, with the outside effort leading the learning curve. We will use the 3rd testbed cisco as the exclusively-OSI gateway. It has 2 ethers and we can possibly add a 3rd 3COM board. (Note: we are still awaiting new ROMs for this cisco). It would be connected to the Transit LAN (Alternet) and to net 3. Thus, it would be the interface to the outside and could route initially to net 3 inside. Frequent rebooting for new config files would not be an issue, since it's a dedicated gateway for OSI. A Sun running SunNet OSI 7.0 will be attached to net 3 and act as the test host for initial connectivity tests to Alternet. The current ("production") cisco between testbed nets 1, 2, & 3 would stay as is, until the OSI routing is stable. At that time it would activate the OSI routing in its config file. Thus, IPgw (MicroVax named Radegond), MITREgw, and TBgw would be the IP routers, and OSIgw and TBgw would be the OSI routers. Later, Radegond could be modified to take over OSI routing for the IE Testbed with properly designed and integrated OSI routing and instrumentation/logging. The picture looks like this: Early end to end testing can be done across Alternet to Nordunet (to which they're directly attached). Both Alternet and Nordunet are totally online with OSI and are awaiting our participation. When OSI routing is working well among the local testbed networks, the T1 line to DCEC (DCECgw) and their systems can be included in the effort. Their addresses and assignments need to be designed. 1.4.2 Washington (inside) The IE Testbed environment is purely IP and CLNP, and resides outside the MITRE production environment. Testing inside MITRE will show compatibility with additional protocols (mainly Appletalk and Novell IPX). We're preparing a matrix T1 | +-----------+ |Alternet-gw| +-----------+ | --------------------------Transit-LAN | | | +----+ +-----+ +-------+ |IPgw| |OSIgw| |MITREgw|-------MITRE-LAN +----+ +-----+ +-------+ | | | -------------1 ---------3 | | | | +------+ +-----+ +---+ |DCECgw| |TB-gw| |Sun| +------+ +-----+ +---+ | | T1 ------2 Figure 2. of which ciscos route/bridge which protocols. Some backbone segment and appropriate subnet(s) can be used to see that that protocol mix will co-exist properly. Once that's shown to be workable, then we can turn on OSI routing or bridging in the T-1 link between Bedford and Washington. Testing can then be performed between the two campuses. The link to Colorado Springs can be activated. Extension into the rest of either campus can proceed independently. 1.4.3 Bedford (inside) Dave Miller writes: I wanted to let you know what our OSI router testbed looks like in Bedford. We currently have 1 cisco and 2 3Com routers routing OSI over 4 subnets. The config looks something like this: As far as I know we're the only people at Bedford routing OSI traffic, but all of the other cisco's in the Bedford backbone have bridging enabled and should pass OSI traffic. Once you guys get your routers setup - it should be fairly easy to route traffic between testbeds - just a few static routes pointing to your testbed. ------------------------------------ MITRE Ethernet | ----------- | cisco |---------------------- ----------- subnet 0004 | | ------------------- ----------------------- subnet 0001 | | subnet 0002 | ----------- ---------- | 3Com | | 3Com | ----------- ---------- | ----------------------- subnet 0003 Figure 3. We're currently using OSInet address space in Bedford, but I'd like to start using GOSIP 2 (IS-IS) style addresses. Our addresses currently look like: AFI=47 IDI=0004 ORG=0018 SUBNET=000X SYSTEM-ID=XXXXXXXXXXXX N-SEL=XX 1.4.4 Tools There are several tools around for testing (Argo, ISODE, and private). PING -- There is an OSI ping (called "clnpping") that's in /usr/local/bin on the testbed MicroVaxen. It came with the Argo code from U. Wisconsin, and has probably been modified since. TRACEROUTE -- Merit has used the Argo software to create a "traceroute". We will be trying to obtain a copy. PACKET DUMP -- There is now a single packet trace program for TCP and OSI traffic. ("trace -o" and "trace -t"). The program was formerly called "TCPtrace". These tools may need modification when used with other OSI software. The Wisconsin stuff uses the old RFC 986 style NSAPs only and the tools probably can't parse anything else. The changes needed should not be major. 1.5 ISSUES 1.5.1 Security Filtering The concern is the limiting of traffic to and from a few designated hosts. The current cisco filtering of IP traffic does not have a direct counterpart in CLNP. Conversations with cisco are making our needs known. 1.5.2 Washington Test Facilities Which systems will be used on the production LAN for testing? Can a couple of Macintoshes be loaned for Appletalk testing on the IE Testbed before testing on the production LAN? 1.5.3 OSI Site Testing Which site will be used to test the Alternet connection? Will we need to take a Testbed Sun to Alternet to act as an intermediate test host? 1.5.4 Alternate Routes What's the mechanism going to be to advertise a "private" AA across many regionals?